- From: Marcos Caceres <marcosc@opera.com>
- Date: Mon, 8 Jun 2009 13:07:45 +0200
- 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." Fixed. > 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. > ECDSA-SHA-256 > 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 http://datadriven.com.au
Received on Monday, 8 June 2009 11:08:42 UTC