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

Received on Monday, 8 June 2009 11:08:42 UTC