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

I've added this to the Widgets Signature specification.

regards, Frederick

Frederick Hirsch
Nokia



On Apr 23, 2009, at 3:18 AM, ext Priestley, Mark, VF-Group wrote:

> Thanks Frederick!
>
>
> -----Original Message-----
> From: Frederick Hirsch [mailto:Frederick.Hirsch@nokia.com]
> Sent: 22 April 2009 23:20
> To: Priestley, Mark, VF-Group
> Cc: Frederick Hirsch; marcosc@opera.com; Barstow Art (Nokia-CIC/ 
> Boston);
> public-webapps
> Subject: Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec
> published on March 31
>
> I think the following items are fine and will add them to the spec:
>
> Signing parties are expected to ensure that the dsp:Identifier  
> signature
> property value is unique for the widgets that they sign" 5.5 and 7.2
>
> I don't think there is anything else, though we need to check the  
> blogs
> and also to see if any new mistakes have been introduced.
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Apr 22, 2009, at 5:53 PM, ext Priestley, Mark, VF-Group wrote:
>
>> Thanks Frederick and Marcos - responses inline.
>>
>> Only a couple of questions left :)
>>
>> Regards,
>>
>> Mark
>>
>> -----Original Message-----
>> From: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On
>> Behalf Of Marcos Caceres
>> Sent: 22 April 2009 11:46
>> To: Frederick Hirsch; Priestley, Mark, VF-Group
>> Cc: Barstow Art (Nokia-CIC/Boston); public-webapps
>> Subject: 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
>>
>> [mp] Thanks
>>
>>>
>>>>
>>>>
>>>> -----
>>>> 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
>>
>> [mp] Thanks
>>
>>>
>>>> -----
>>>> 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.
>>
>> [mp] I'm OK either way.
>>
>>>
>>>> -----
>>>> 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?
>>
>> [mp] No, it's mostly a case of me needing to read the text more
>> carefully! My confusion was caused by the fact we only define the
>> namespace prefixes that we use in throughout the spec in the context
>> of resources.
>>
>>>>
>>>>
>>>> -----
>>>> "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 :)
>>
>> OK - my concern was just that [XMLSecAlgs] cross references lots of
>> algorithms that we don't need but happy to leave as it is.
>>
>>>
>>>> -----
>>>> 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.
>>
>> [mp] OK for me
>>
>>>> -----
>>>> "physical file" -> file ?
>>>>
>>>
>>> Marcos? ok with file personally
>>
>> Agree.
>>
>> [mp] Thanks
>>
>>>> -----
>>>> "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.
>>
>> [mp] As I can't think of anything better, happy to leave as is.
>>
>>>> -----
>>>> "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.
>>
>> [mp] proposal "of the widget package, which logically contain one or
>> more file entries, as defined"
>>
>> Note that reading this again - if a file entry is a file or a folder,
>> then there must be at least one file entry unless the widget is an
>> empty package (and if it's signed it can't be empty because at a
>> minimum there would be a signature file entry!) so I think one one or
>> more is correct.
>>
>>>
>>>> -----
>>>> 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".
>>
>> [mp] OK, makes sense.
>>
>>>> -----
>>>> "(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.
>>
>> [mp] OK
>>
>>>
>>>> -----
>>>> 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.
>>
>> [mp] thanks
>>
>>>
>>>
>>>>
>>>>
>>>> -----
>>>> 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
>>
>> [mp] Thanks
>>
>>>
>>>> -----
>>>> "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?
>>
>> [mp] Well if we think of security policy in the broadest sense, any
>> decision of which signatures to process is part of the security
>> policy. The UA has to do something! Changing "used" to "enforced"
>> could make it clearer. Alternatively simply deleting the sentence
>> would work.
>>
>>>
>>>>
>>>>
>>>> -----
>>>> "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
>>
>> [mp] Thanks
>>
>>>
>>>>
>>>>
>>>> -----
>>>> 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
>>
>> [mp] Thanks
>>
>>>
>>>> -----
>>>> 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.
>>
>> [mp] You're right - my mistake
>>
>>>
>>>> -----
>>>> 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.
>>
>> [mp] OK
>>
>>>
>>>>
>>>>
>>>> -----
>>>> "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
>>
>> [mp] Thanks
>>
>>>
>>>> -----
>>>> 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
>>
>> [mp] Thanks
>>
>>>
>>>> -----
>>>> 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
>>
>> [mp] OK - but we earlier say "A  user agent is an implementation that
>> attempts to support this specification." Therefore isn't a UA also an
>> implementation?
>>
>>>
>>>> -----
>>>> 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?
>>
>> [mp] Proposal: "Signing parties are expected to ensure that the
>> dsp:Identifier signature property value is unique for the widgets  
>> that
>
>> they sign"
>>
>>>
>>>
>>>>
>>>>
>>>> -----
>>>> 7.1
>>>>
>>>> "Each ds:Signature property" -> "Each ds:SignatureProperty" ?
>>>>
>>>
>>> meant as written since wanted to be clear about properties as  
>>> opposed
>
>>> to XML representation.
>>
>> [mp] OK
>>
>>>
>>>> -----
>>>> 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)
>>
>> [mp] OK - digest algorithms are covered in 3.b.
>>
>>>
>>>> -----
>>>> 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?
>>
>> [mp] Proposal (as above): "Signing parties are expected to ensure  
>> that
>
>> the dsp:Identifier signature property value is unique for the widgets
>> that they sign"
>>
>>>
>>>>
>>>>
>>>> -----
>>>> 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.
>>
>> [mp] Perfect - thanks
>>
>>>
>>>>
>>>>
>>>> -----
>>>> 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
>>
>> [mp] Thanks
>>
>>>
>>>>
>>>>
>>>> -----
>>>> 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.
>>
>> [mp] It was meant to remove the inconsistency, however, re-reading  
>> the
>
>> intro to section 9 (which I managed to skip even though it's in bold,
>> red text) I realise that this section is to be removed from the  
>> Widget
>
>> 1.0: Digital Signatures specification, so there is no inconsistency.
>> My mistake.
>>
>>>
>>>>
>>>>
>>>> -----
>>>> 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...
>>>
>>
>> [mp] See above comment - my mistake
>>
>>>>
>>>>
>>>> -----
>>>> "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.
>>
>> [mp] and again, based on a misunderstanding of why this text was
>> included.
>>
>>>
>>>>
>>>>
>>>> -----
>>>> 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
>>>
>>
>> [mp] and same response - my error
>>
>>>>
>>>>
>>>>
>>>>> -----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 Thursday, 23 April 2009 12:16:37 UTC