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

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

>
>
> -----
> "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?

> -----
> "physical file" -> file ?
>

Marcos? ok with file personally

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

> -----
> "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?


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

> -----
> "(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
>>
>>
>

Received on Tuesday, 21 April 2009 21:15:10 UTC