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

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.

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 12:32:21 UTC