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

XML Signature 1.1 should be referenced. It defines the URI for the  
algorithms, context for use in XML Signature, and references etc.

regards, Frederick

Frederick Hirsch
Nokia



On Jun 8, 2009, at 8:30 AM, ext Marcin Hanclik 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.
>
> 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:44:23 UTC