W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

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

From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Date: Mon, 8 Jun 2009 09:50:48 -0400
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>, "Barstow Art (Nokia-CIC/Boston)" <Art.Barstow@nokia.com>, public-webapps <public-webapps@w3.org>, "public-xmlsec@w3.org" <public-xmlsec@w3.org>
Message-Id: <1FE73DB4-5EAA-46CF-8383-64BA33324A36@nokia.com>
To: "marcosc@opera.com" <marcosc@opera.com>
1) inconsistency question

> 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.

should be ECDSAwithSHA256 , is that the extent of the inconsistency  
question?

xml signature 1.1 algorithms section

http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Algorithms

2) Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any  
specs

I believe we should refer to XML SIgnature 1.1 which then provides  
appropriate material

3) section 6 vs section 7.1

I suggest we keep the language as is. 7.1 says you must use an  
algorithm in section 6, section 6 says you must support certain ones,  
and may support others. There is nothing inconsistent or wrong here.  
Thus if we change the rules in section 6 we do not need to change  
section 7.

(I thought we decided on the last wg call to freeze the spec but I  
guess not... )

regards, Frederick

Frederick Hirsch
Nokia



On Jun 8, 2009, at 7:07 AM, ext Marcos Caceres wrote:

> 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
Received on Monday, 8 June 2009 13:52:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT