- From: Marcos Caceres <marcosc@opera.com>
- Date: Mon, 8 Jun 2009 15:07:58 +0200
- To: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Cc: "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>, Frederick Hirsch <frederick.hirsch@nokia.com>, Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>, "public-xmlsec@w3.org" <public-xmlsec@w3.org>
On Jun 8, 2009, at 2:30 PM, Marcin Hanclik <Marcin.Hanclik@access-company.com > wrote: > Hi Marcos, > >>> Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any >>> specifications? Do they have a corresponding spec? > > DSA-SHA-1 > ANSI X9.57 DSA signature generated with SHA-1 hash (DSA x9.30) > http://www.oid-info.com/get/1.2.840.10040.4.3 > SHA-1 > http://www.itl.nist.gov/fipspubs/fip180-1.htm > > > RSA-SHA-256 > RSA > http://tools.ietf.org/rfc/rfc2437.txt > SHA-256 > http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf > > ECDSA-SHA-256 > ECDSA is specified in X9.62 > http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.62%3a2005 > (paid resource) > In RFCs it is referred to as: > [X9.62] American National Standards Institute. ANSI X9.62-1998, > Public Key Cryptography for the Financial Services Industry: > The Elliptic Curve Digital Signature Algorithm. January 1999. > SHA-256 as above > > For SHA-XXX alternatively the following can be used: > http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf > (includes SHA-1, SHA-256 and more) > > Thanks. > Thanks Marcin, that's great! If I get the ok from Frederick, I'll add them in. > Kind regards, > Marcin > > Marcin Hanclik > ACCESS Systems Germany GmbH > Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 > Mobile: +49-163-8290-646 > E-Mail: marcin.hanclik@access-company.com > > -----Original Message----- > From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org > ] On Behalf Of Marcos Caceres > Sent: Monday, June 08, 2009 1:08 PM > To: Priestley, Mark, VF-Group; Frederick Hirsch > Cc: Arthur Barstow; public-webapps; public-xmlsec@w3.org > Subject: Re: Reminder: Comments for LCWD of Widgets 1.0: Digital > Signatures due June 1 > > 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 > > > ________________________________________ > > Access Systems Germany GmbH > Essener Strasse 5 | D-46047 Oberhausen > HRB 13548 Amtsgericht Duisburg > Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda > > www.access-company.com > > CONFIDENTIALITY NOTICE > This e-mail and any attachments hereto may contain information that > is privileged or confidential, and is intended for use only by the > individual or entity to which it is addressed. Any disclosure, > copying or distribution of the information by anyone else is > strictly prohibited. > If you have received this document in error, please notify us > promptly by responding to this e-mail. Thank you.
Received on Monday, 8 June 2009 13:09:32 UTC