RE: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1

Hi Art, All,

Vodafone has some late comments which it would like to provide to the
group for consideration and apologise for supplying these after the
deadline.

We believe that all but one of the comments is editorial and so there
inclusion or otherwise should not affect or delay the decision to go to
CR status, which we support. In submitting these comments it is not our
intention or desire to hold up this process, only to provide the
comments for consideration. 

The only comment that doesn't fit into this category is a question that
has been raised by one of our developers. My hope is that there is
already an answer!

Thanks,

Mark

-----------------------
Editorial Comments
-----------------------

-------[Definition of file entry]-------

Section: 1.2

"A file entry is the compressed (or Stored [ZIP]) representation of a
physical file or folder contained within a widget package, as defined in
the [Widgets Packaging] specification."

In Widgets 1.0: Packaging and Configuration [2] the file entry
definition is different.

"A file entry is the data held by a local file header, file data, and
(optional) data descriptor, as defined in the [ZIP] specification, for
each physical file contained in a Zip archive."

Comment - the inclusion of folder in the definition in [1] has caused
one reviewer to ask if there should be a reference element for folders?
I believe this is not the case and "or folder" could be removed from the
definition.

-------[Requirements accuracy]-------

Section: 2

"R52. Support for Multiple Signature Algorithms: DSA-SHA-1, RSA-SHA-1,
DSA-SHA-256 and RSA-SHA-256."

Are these algorithms still correct? DSA-SHA-256 and RSA-SHA-1 should
probably be removed as they are not required algorithms. ECDSA-SHA-256
could be added. 

[Conflict between mandatory statements]

"A user agent MAY support additional signature algorithms." (Section:
6.1)
"A user agent MAY support additional digest methods." (Section: 6.2)
"A user agent MAY support additional XML canonicalization methods."
(Section: 6.3)

Section: 7.1
"The Algorithm attribute of the ds:digestMethod MUST be one of the
digest algorithms."
"The Algorithm attribute of the ds:CanonicalizationMethod element MUST
be one of the canonicalization algorithms."
"The ds:SignatureMethod algorithm used in the ds:SignatureValue element
MUST be one of the signature algorithms."

Comment - If in section 6 we say "A user agent MAY support additional
XXX algorithms", which seems to be in conflict with section 7 that
states the algorithm used must be one of algorithms listed in section 6.
This seems to be an open ended requirement.

Suggestion - Remove the statements in section 7.1. It is down to the
signer to choose the algorithm to use. If they choose to use a
non-recommended algorithm they should understand that user agent support
cannot be guaranteed. 

-----------------------
Question / non-editorial
-----------------------

-------[Support for certificate chains]-------

Typically more than one X509 certificate will need to be included in the
signature in order to construct a certificate chain to an installed root
certificate. Ideally the widget user agent would be given an indication
of how to re-construct the certificate chain. This could be done my
recommending that X509Certificate elements be included in certificate
chain order or by including an attribute to the element, e.g.

<X509Data>
	 <X509Certificate order="1">...</X509Certificate>
	 <X509Certificate order="2">...</X509Certificate>
	 <X509Certificate order="3">...</X509Certificate> </X509Data>

Maybe this is already solved with other uses of XML Digital Signatures?


[1] http://dev.w3.org/2006/waf/widgets-digsig/
[2] http://www.w3.org/TR/widgets/#definitions

  



  





 

-----Original Message-----
From: public-webapps-request@w3.org
[mailto:public-webapps-request@w3.org] On Behalf Of Arthur Barstow
Sent: 21 May 2009 18:23
To: public-webapps; public-xmlsec@w3.org
Subject: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures
due June 1

Hi All - a friendly reminder June 1 is the end of the comment period for
the April 30 Widgets 1.0: Digital Signatures Last Call Working
Draft:

  <http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/>

Please send all comments by June 1.

-Regards, Art Barstow


On May 1, 2009, at 10:48 AM, Barstow Art (Nokia-CIC/Boston) wrote:

> On April 30 the WebApps WG published a LCWD of the Widgets 1.0 Digital

> Signatures spec:
>
> [[
> <http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/>
>
> Introduction
>
> This document defines a profile of the XML Signature Syntax and 
> Processing 1.1 specification to allow a widget package to be digitally

> signed. Widget authors and distributors can digitally sign widgets as 
> a mechanism to ensure continuity of authorship and distributorship. 
> Prior to instantiation, a user agent can use the digital signature to 
> verify the integrity of the widget package and to confirm the signing 
> key(s). This document specifies conformance requirements on both 
> widget packages and user agents.
>
> A widget package can be signed by the author of the widget producing 
> an [XMLDSIG11] signature that cryptographically includes all of the 
> file entries other than signature files. A widget package can also be 
> signed by one or more distributors of the widget, producing 
> [XMLDSIG11] signatures that each cryptographically includes all of the

> non-signature file entries as well as any author signature.
> ]]
>
> We explicitly seek comments from the XML Security WG; comments from 
> other WGs as well as the TAG are welcome.
>
> The comment period ends 1 June 2009.
>
> All comments should be sent to public-webapps@w3.org [1].
>
> -Regards, Art Barstow
>
> [1] <http://lists.w3.org/Archives/Public/public-webapps/>
>
>

Received on Thursday, 4 June 2009 12:28:18 UTC