Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31

On Tue, Apr 21, 2009 at 11:14 PM, Frederick Hirsch
<frederick.hirsch@nokia.com> wrote:
> Mark
>
> Please find responses  inline. Thanks for the review.
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Apr 7, 2009, at 2:27 AM, ext Priestley, Mark, VF-Group wrote:
>
>>
>> Hi Art, All,
>>
>> Please find below my editorial comments and requests for clarifications
>> based on the new WD [1]. While it is a long list the comments are all
>> minor and so hopefully easily addressed. Overall I think the spec is
>> looking good, for which a lot of thanks must go to Frederick and Marcos!
>>
>> That said, I have a couple of more substantive comments that I will send
>> in the next couple of days.
>>
>> Many thanks,
>>
>> Mark
>>
>>
>> [1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/
>>
>> -----
>> COMMENTS
>> -----
>>
>> 1.0
>>
>> "A widget package can be signed by the author of the widget producing an
>> [XMLDSIG11] signature that cryptographically includes all of the file
>> entries other than signature files. A widget package can also be signed
>> by one or more distributors, with XML signatures that each
>> cryptographically includes all of the non-signature file entries as well
>> as any author signature."
>>
>> Change the last sentence for consistency between definitions, ie:
>>
>> "... A widget package can also be signed by one or more distributors
>> <change> of the widget, producing [XMLDSIG11] </change> signatures that
>> each cryptographically includes all of the non-signature file entries as
>> well as any author signature."
>
> ok
>
>>
>>
>> -----
>> Can we remove the following sentence? This is a general property of
>> signatures which I'm not sure we need to include.
>>
>> "Digitally signing implies use of private key material only known by the
>> signer, thus enabling verification of integrity and signature source."
>
> ok
>
>> -----
>> 1.1
>>
>> We don't actually define any XML elements in the
>> "http://www.w3.org/ns/widgets-digsig" namespace... is this worth noting
>> this and/or removing the "wsig" prefix?
>>
>
> We define URIs using this namespace so we should keep the URI definition.
> ok with removing prefix since it is not used now but would prefer to keep to
> avoid errors later. Not a big issue to remove though.
>
>> -----
>> The terms "XML elements" and "resources" seem to be used
>> interchangeably? Is there a difference?
>
> yes, one is xml elements others are resources as referenced by URI

Mark, I'm worried you asked this question? Is there confusion
somewhere wrt to the use resource and xml elements?

>>
>>
>> -----
>> "Algorithms used by XML Security are defined in a number of places..." -
>> could we tighten up this sentence, eg something like "This specification
>> references algorithms defined in [XMLSecAlgs] and [XMLDSIG11]" ?
>>
>
> No, XMLSecAlgs does not define the algs. There are defined in a number of
> places :)
>
>> -----
>> 1.2
>>
>> "compressed (or Stored)" - either remove capitalisation of Stored or add
>> it to compressed
>>
>
>
> I suggest "stored". Marcos?

Stored should probably be [Stored], with a reference to the RFC for
the algorithm.

>> -----
>> "physical file" -> file ?
>>
>
> Marcos? ok with file personally

Agree.

>> -----
>> "top-most path level" - is there a better way of saying this?
>>
>
> don't think so unless you have a proposal without using the word "root"

I know it's nasty, but people understand it. Lets play wordsmith only
once we have all the tech stuff solved.

>> -----
>> "which MAY logically contain" - if the configuration file is made
>> mandatory then the MAY should be a MUST
>>
>
> I think it is a MAY,  others?

Technically, Mark is correct. But leave it as a MAY (or maybe drop MAY
altogether) because this spec does not put conformance criteria on
packaging.

>
>> -----
>> Question: is a file entry the same as a file? If so then we should
>> always use "file entry" in place of "file". If not then perhaps we
>> should define file?
>>
>
> I don't think they are the same. This is a P&C question. Marcos?

Depends. A file entry is the representation of file data in a zip
archive. A file is a physical uncompressed file as would appear on
disk. If we assume that signatures will act on physical files, it will
be correct to talk about "files".

>> -----
>> "(i.e., a third party that is distributing the widget on behalf of the
>> author)." - in some cases the author may also be (one of) the
>> distributor(s). suggest changing "i.e." to "e.g."
>>
>
> I think i.e. is correct. In the case you suggest they just happen to be the
> same entity fulfilling two roles.
>
>> -----
>> 3
>>
>> "As well as sections marked as non-normative, examples and notes in this
>> specification are non-normative. Everything else in this specification
>> is normative. The security considerations section is non-normative."
>>
>> Suggest change to the following for readability:
>>
>> "As well as sections marked as non-normative, the examples and notes,
>> and security considerations in this specification are non-normative.
>> Everything else in this specification is normative."
>
> yes, better.
>
>
>>
>>
>> -----
>> 4
>>
>> "This section defines how to locate digital signatures in a widget
>> package for processing. An implementation MUST achieve the same result
>> as the following algorithm used to locate digital signatures in a widget
>> package:"
>>
>> In the sentence above, change "digital signatures" to "signature files"
>> (in both cases)
>>
>
> ok
>
>> -----
>> "This MAY be determined by the security policy used by the user agent."
>>
>> Can we say will or, better yet, SHOULD or MUST? Otherwise, what do we
>> mean when we say MAY? Who (what) else may enforce security policy?
>
> we mean may since security policy is out of scope. How can we mandate what
> is not defined?
>
>>
>>
>> -----
>> "Thus the highest numbered distributor signature would be validated
>> first."
>>
>> Change to:
>>
>> "Thus in the case that one or more distributor signatures were
>> validated, the highest numbered distributor signature would be validated
>> first."
>
> ok
>
>>
>>
>> -----
>> 5.1
>>
>> "A widget package MAY be digitally signed using XML Signature
>> [XMLDSIG11]."
>>
>> don't we mean:
>>
>> "A widget package MAY be digitally signed using the profile of XML
>> Signature [XMLDSIG11] defined by this specification." ?
>>
>
> ok
>
>> -----
>> As this section is talking about generating a signature, I suggest that
>> we remove "and validated" in the following sentence:
>>
>> "Each signature file MUST be generated and validated in"
>>
> No -  6.1 applies to both generation and validation, common to both.
>
>> -----
>> 5.2
>>
>> As per previous email exchange we need to re-work author signature
>> definition
>
>> -----
>> "zero or one author signatures." - remove final "s"
>
> No, I think that the current is correct grammatical usage and clear in
> meaning.
>
>>
>>
>> -----
>> "This represents the digital signature of the author of the widget
>> package."
>>
>> add "signature file" ie "This signature file represents the digital
>> signature of the author of the widget package."
>>
> ok
>
>> -----
>> 5.3
>>
>> "This represents the digital signature of a distributor of the widget
>> package."
>>
>> add "signature file" ie "This signature file represents the digital
>> signature of a distributor of the widget package."
>>
>
> ok
>
>> -----
>> 5.3.1
>>
>> "Within a widget package these signature files MUST be ordered based on
>> the numeric portion of the signature file name.
>>
>> Thus, for example, signature2.xml precedes signature11.xml."
>>
>> Question: what does this mean? What is it requiring from a widget
>> package?
>>
>> -----
>> 5.4
>>
>> "Implementations MUST be prepared to accept X.509 v3 certificates
>> [RFC5280]."
>>
>> Can we say "User agents" rather than implementations
>>
> we mean implementations
>
>> -----
>> 5.5
>>
>> "It MUST be unique for a given signer."
>>
>> Do we need to make it clear that we are not expecting the UA to check
>> this? I take it we're not asking the UA to check this, right?
>
> What do you suggest we say?
>
>
>>
>>
>> -----
>> 7.1
>>
>> "Each ds:Signature property" -> "Each ds:SignatureProperty" ?
>>
>
> meant as written since wanted to be clear about properties as opposed to XML
> representation.
>
>> -----
>> In step 5 there is no bullet for digest algorithms, which there probably
>> should be.
>>
>
> I believe digest algorithms are mentioned for ds:References for the
> digesting of content, but not needed in step 5 since the signature method
> includes the digest method (eg RSAwithSHA256)
>
>> -----
>> 7.2
>>
>> "This MUST be a unique signing string for all signature files created by
>> the signer." - same comment as 5.5. ie - Do we need to make it clear
>> that we are not expecting the UA to check this?
>
> What do you suggest we say?
>
>>
>>
>> -----
>> 7.3
>>
>> "If signature file validation fails for any reason, any external
>> entities (e.g., a user agent that implements [Widgets Packaging])
>> relying on the validation of the signature file MUST be notified of the
>> failure..."
>>
>> Maybe we should say that notification of successful validation must also
>> be provided?
>
> Add before the last paragraph?:
>
> If signature validation is successful any external entities (e.g., a user
> agent that implements [Widgets Packaging]) relying on the validation of the
> signature file MUST be notified of the success.
>
>>
>>
>> -----
>> 8
>>
>> "A signature file may also be renamed, which can affect processing."
>> suggest modification to "...which can affect the order in which
>> distributor signatures are processed"
>
> ok
>
>>
>>
>> -----
>> 9.1.1
>>
>> "Upon signature generation, if this property is used, the value is set
>> to ..."
>>
>> Is inconsistent with the sentence from 5.1 which states:
>>
>> "Each signature file MUST contain a dsp:Identifier signature properties
>> element compliant with XML Signature Properties [XMLDSIG-Properties] and
>> this specification."
>>
>
> this is not inconsistent. Section 9 says if used, section 5.1 says it is
> used in the profile...
>
>> Suggest deletion of ", if this property is used," from the first
>> sentence
>
> I do not think I understand the rationale for this change.
>
>>
>>
>> -----
>> 9.1.2
>>
>> "Profiles MUST specify details of the identifier property value creation
>> and interpretation." What does "Profiles" mean in this sentence
>
> the widgets signature specification is a profile...
>
>>
>>
>> -----
>> "If multiple instances of this property are found on a single signature,
>> then applications MUST NOT deem any of these properties valid." - which
>> would in turn mean that the signature was invalid, right? We may want to
>> state this?
>
> the properties are not valid though the signature still might be valid.
> Interpretation of properties is profile dependent.
>
>>
>>
>> -----
>> 9.2
>>
>> Note that the same comments may apply to 9.2.1 and 9.2.2 dependent on
>> the discussions on the mandatory/optional status of this property.
>
> same answers as for 9.1.2
>
>>
>>
>>
>>> -----Original Message-----
>>> From: public-webapps-request@w3.org
>>> [mailto:public-webapps-request@w3.org] On Behalf Of Arthur Barstow
>>> Sent: 02 April 2009 17:21
>>> To: public-webapps
>>> Subject: [widgets] New WD of Widgets 1.0: Digital Signatures
>>> spec published on March 31
>>>
>>> On March 31 a new WD of the Widgets 1.0 Digital Signature spec
>>> was published and announced on the W3C's home page:
>>>
>>> [[
>>> 2009-03-31: The Web Applications Working Group has published a
>>> Working Draft of Widgets 1.0: Digital Signatures. This
>>> document defines a profile of the XML Signature Syntax and
>>> Processing 1.1 specification to allow a widget package to be
>>> digitally signed.
>>> Widget authors and distributors can digitally sign widgets as
>>> a trust and quality assurance mechanism. Prior to
>>> instantiation, a user agent can use the digital signature to
>>> verify the integrity of the widget package and perform source
>>> authentication. This document specifies conformance
>>> requirements on both widget packages and user agents.
>>> ]]
>>>
>>> Please review this new WD as soon as possible, preferably
>>> within the next two weeks:
>>>
>>> <http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/>
>>>
>>> -Regards, Art Barstow
>>>
>>>
>>
>
>
>



-- 
Marcos Caceres
http://datadriven.com.au

Received on Wednesday, 22 April 2009 10:46:50 UTC