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

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

From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Date: Wed, 22 Apr 2009 17:15:56 -0400
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, "ext Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>, "Barstow Art (Nokia-CIC/Boston)" <Art.Barstow@nokia.com>, public-webapps <public-webapps@w3.org>
Message-Id: <25221C4D-C111-4E9C-947D-EC06445E73C8@nokia.com>
To: "marcosc@opera.com" <marcosc@opera.com>
Two proposals based on Marcos comments

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


Dropped MAY for reason Marcos mentioned, also since not really  
appropriate to definition.


>>> 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 don't think we can always expect creation of a physical file for  
processing. Suggest not making any  change here.

regards, Frederick

Frederick Hirsch
Nokia



On Apr 22, 2009, at 6:45 AM, ext Marcos Caceres wrote:

> 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 21:17:15 GMT

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