Hi Marcos, These are my further comments to the DigSig spec:
1. There is no section about typographic conventions, as e.g. section 1.3 in P&C spec. Therefore it is not possible to know e.g. which part of the spec is defining an example. 2. Section 4. My below comment "5. Section 4, item 3:" is invalid, since ASCII sorting will not guarantee that signature2.xml will appear before signature11.xml when sorted. I am sorry for confusion. 2.a. Section 4, item 6: Correspondingly to the above: "descending order" could become "descending numerical order" I would also define numerical order by taking an excerpt from another part of the spec: "Numerical order is the order based on the numeric portion of the signature file name." 2.b. Section 4, item 6: "The ordering by file name can be used to allow consistent processing and possible optimization." The term "ordering by file name" may be misinterpreted in the context of the numerical order, so I think that the whole statement could be removed. 3. Section 4 + Section 5.3.1: Section 4 implies that "sorting" is an operation that takes place after the signature files are found within the widget package. So I would change the text in Section 5.3.1. to distinguish between "sorting" (an operation) and file order in the widget package: "These signatures MUST be sorted numerically based on the numeric portion of the name." could become "Within a widget package these signature files MUST be ordered based on the numeric portion of the signature file name." The general question is whether the signature files MUST be ordered in the widget package, since the processing algorithm assumes that the signature files are sorted anyway after being extracted from the widget package. Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Europe GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -----Original Message----- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcin Hanclik Sent: Thursday, March 26, 2009 8:42 PM To: marc...@opera.com; WebApps WG; otsi-arch-...@omtplists.org Subject: RE: [BONDI Architecture & Security] [widgets] new digsig draft Hi, One correction to what I wrote: Instead of a) Replace "root of the archive" with "root of the widget" I would now suggest a) Replace "root of the archive" with "root of the widget package" Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Europe GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -----Original Message----- From: otsi-arch-sec-ow...@omtp.ieee-isto.org [mailto:otsi-arch-sec-ow...@omtp.ieee-isto.org] On Behalf Of Marcin Hanclik Sent: Thursday, March 26, 2009 7:05 PM To: marc...@opera.com; WebApps WG; otsi-arch-...@omtplists.org Subject: RE: [BONDI Architecture & Security] [widgets] new digsig draft Hi Marcos, All, Please find below my - mostly editorial - comments to the latest digsig draft and one comment for P&C. Thanks. Kind regards, Marcin 1. Section 1: "... with XML signatures that each cryptographically include all of the non-signature ..." should become (missing "s") "... with XML signatures that each cryptographically includes all of the non-signature ..." 2. Unify "case sensitive" phrase. There are now both "case-sensitive" and "case sensitive" present in the text. 3. Section 1.2: Maybe the common terms could be unified between DigSig and P&C? Both specs will probably be always used together. "A file entry is the compressed (or Stored) representation of a physical file or folder contained within a widget package, as defined in the [Widgets Packaging] specification. The root of the archive is the top-most path level of the widget package, which MAY logically contain one or more file entries, as defined in the [Widgets Packaging] specification. A file name is the name of a file contained in a widget package (derived from the file name field of a local file header of a file entry), as defined in the [Widgets Packaging] specification. All file names MUST be treated as case-sensitive. In other words, case matters in file name comparisons. " Proposed changes: a) Replace "root of the archive" with "root of the widget" b) Clarify "file name" in P&C (the definition in DigSig says about deriving from file name field and it seems strange to me). c) Replace all the lines above with the following: "The file entry, root of the widget and file name terms are to be interpreted as defined in the [Widgets Packaging] specification." 4. Section 1.2: "This specification uses [ABNF] syntax to define file names. Rules are concatenated by being written next to each other. A rule ended by * means zero or more. See [ABNF] for details on this syntax." -> "This specification uses [ABNF] syntax to define file names." Additional clarifications may only confuse the reader, since [ABNF] is detailed enough and the actual semantics remains the same. 5. Section 4, item 3: "ascending numerical order" -> numerical order is implied by simple ASCII sorting, so I suggest "ascending numerical order" becomes simply "ascending order". This would also match the "descending order" in item 6 where "numerical" is not present. 6. Section 4, item 5: ".. treat this as.." -> what is "this"? I suggest to change the text to "... treat this widget package as ..." 7. Section 4, item 6: "Validate the signature files in the signatures list" -> "signatures" looks weird, the cause is <var> vs. <code> in HTML. 8. Section 5.3.1: "A file entry whose file name that does not match the" -> "that" should be removed 9. Section 5.4: identify the X.509 version fully. "The X.509 certificate format MUST" could become "The X.509v1 certificate format MUST" 9.a. The following references can be added: 9.a.i. X.509v1: http://www.itu.int/rec/T-REC-X.509-198811-S/en 9.a.ii. X.509v3: http://www.itu.int/rec/T-REC-X.509-199708-S/en 10. Section 7.2: The time SHOULD reflect the time that signature generation completes. -> The time SHOULD reflect the time when signature generation completed. 11. Section 7.3: If present then user agents MUST perform Basic -> If present, the user agents MUST perform Basic 12. Section 9.2.1: The time SHOULD reflect the time that signature generation completes. -> The time SHOULD reflect the time when signature generation completed. BTW: Comment to P&C: 1. RFC 2119 terms are in lower-case in P&C, whereas DigSig uses upper-case (that is more common). Marcin Hanclik ACCESS Systems Europe GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -----Original Message----- From: otsi-arch-sec-ow...@omtp.ieee-isto.org [mailto:otsi-arch-sec-ow...@omtp.ieee-isto.org] On Behalf Of Marcos Caceres Sent: Wednesday, March 25, 2009 4:42 PM To: WebApps WG; otsi-arch-...@omtplists.org Subject: [BONDI Architecture & Security] [widgets] new digsig draft Hi All, A new Working Draft of the Widgets 1.0: Dig Sig is ready to be published [1]. I've put the date of publication as the 31 of March, with the hope the W3C will publish it some time next week. If possible, the editors would be greatly appreciate if someone could check over it before it gets published. Please send any feedback you might have by the end of the week. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-digsig/ -- Marcos Caceres http://datadriven.com.au ________________________________________ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you. ________________________________________ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you. ________________________________________ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
