- From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
- Date: Wed, 22 Apr 2009 17:15:56 -0400
- To: "marcosc@opera.com" <marcosc@opera.com>
- 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>
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 UTC