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

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