- From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
- Date: Mon, 8 Jun 2009 09:50:48 -0400
- To: "marcosc@opera.com" <marcosc@opera.com>
- Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>, "Barstow Art (Nokia-CIC/Boston)" <Art.Barstow@nokia.com>, public-webapps <public-webapps@w3.org>, "public-xmlsec@w3.org" <public-xmlsec@w3.org>
1) inconsistency question > 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. should be ECDSAwithSHA256 , is that the extent of the inconsistency question? xml signature 1.1 algorithms section http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Algorithms 2) Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any specs I believe we should refer to XML SIgnature 1.1 which then provides appropriate material 3) section 6 vs section 7.1 I suggest we keep the language as is. 7.1 says you must use an algorithm in section 6, section 6 says you must support certain ones, and may support others. There is nothing inconsistent or wrong here. Thus if we change the rules in section 6 we do not need to change section 7. (I thought we decided on the last wg call to freeze the spec but I guess not... ) regards, Frederick Frederick Hirsch Nokia On Jun 8, 2009, at 7:07 AM, ext Marcos Caceres wrote: > 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 13:52:16 UTC