W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

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

From: Marcos Caceres <marcosc@opera.com>
Date: Mon, 8 Jun 2009 13:07:45 +0200
Message-ID: <b21a10670906080407o1d36e4ffi2d25bbb51ec08294@mail.gmail.com>
To: "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>, Frederick Hirsch <frederick.hirsch@nokia.com>
Cc: Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>, public-xmlsec@w3.org
On Thu, Jun 4, 2009 at 2:27 PM, Priestley, Mark,
VF-Group<Mark.Priestley@vodafone.com> wrote:
> 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.

Using the definition that appears in P&C.

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

I've removed them.

> could be added.

Added, but, Fredrick, there seems to be some inconstancy in the spec
with regards to the use of the algorithm names. Can you please check.

Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any
specifications? Do they have a corresponding spec?

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

I agree.

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

Right. Frederick, wdyt?

Marcos Caceres
Received on Monday, 8 June 2009 11:08:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC