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.hanc...@access-company.com
-----Original Message-----
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@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-xml...@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.priest...@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.