- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Tue, 15 Apr 2008 10:22:58 -0400
- To: public-appformats@w3.org
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, Art Barstow <art.barstow@nokia.com>, XMLSec XMLSec <public-xmlsec-maintwg@w3.org>
I have some comments on the "Widgets 1.0: Digital Signature" W3C Working Draft 14 April 2008, http://www.w3.org/TR/widgets-digsig/ 1) Is it common practice to rely on non-W3C mechanisms for version history (e.g. twitter). It might be preferable to embed version information directly in the document. 2) Shouldn't RFC2119 keywords be capitalized, e.g. MUST. This may require an editorial pass through the document to correct those keywords. Lowercase might lead to confusion since this is often used in a non-normative sense in other specifications. 3) Given the timing of this work, it may make sense to refer to XML Signature, Second Edition and Canonicalization 1.1 both in the text and the URIs given in the examples (once they become RECs). This would be preferable and is a question related to the timing of the final version of this document. 4) It is essential to define versioning for this work. For example, we can expect in the near future to move from SHA-1 to a more secure version of hashing algorithm, etc. Does version rightly belong in signature properties or in widget config.xml? It seems to make sense to be in config.xml (if that is what I think it is) since other widget aspects than signature may also change. 5) Should have a section listing namespaces and noting the fact that prefixes though used for illustration may vary when referring to the namespaces. 6) Section 1 You might want to rephrase: "The resulting signature, along with the signer's digital certificate, is structured into an XML document, and included at the root of a widget resource under the name signature.xml." in p1 section 1 to be "The resulting detached XML Signature is included at the root of a widget resource under the name signature.xml. This XML Signature MUST include the signer's X.509 Certificate in ds:KeyInfo." You should decide if the name is fixed in lowercase or not. State the naming rule here. Is SiGnAtURe.XmL allowed? 7) Section 1.1 Rephrase "The signature scheme defined in this specification imposes a number of restrictions on the XML-Signature Syntax and Processing Specification [XMLDsig]:" to "This specification profiles XML Signature Syntax and Processing Specification [XMLDsig] for widget signing as follows:" 8) I assume 4.4.6 which reads: "Let hash-value be the digests of applying the SHA-1 algorithm to the file entry's decompressed representation (see [XMLDsig] for how to do this)." means: "Define a Transform to decompress the representation and then apply the SHA-1 algorithm to this decompressed representation to create the Reference digest, as outlined in [XMLDsig]." I would add, "Include the Transform in the Reference element." Is there a URI defined for this transform? I'm not sure I exactly understand why you need to decompress to hash and include in the signature. Why not simply sign the binary value and state that is what is signed? If it is so that "see what you sign" is possible then please say so. 9) Section 4. I suggest removing the detailed outline how to do standard XML Signature processing, and simply refer to XML Signature. There may be more than one way to produce the result, so outlining the exact steps may also be too restrictive on implementations. Suggest changing line "The procedure for signing a widget resource to produce a conforming digital signature document is as follows:" to "The result of signing a widget resource to produce a conforming digital signature document MUST have the same effect as the following: 10) Section 5 Replace "The procedure for verifying a digital signature is as follows. The algorithm first checks the validity of the digital signature and then verifies that all resources in a widget resource." with "The procedure for verifying a widget signature is to validate the XML Signature according to [XMLDsig], including Reference digest validation. I agree with Thomas Roessler [1], eliminate the pseudo code in section 5, replacing it with the following sentence: "Successful widget signature validation requires verifying that the XML Signature includes a Reference element for every item in the widget directory and that each Reference hash validates." regards, Frederick Frederick Hirsch Nokia [1] http://lists.w3.org/Archives/Public/public-appformats/2008Apr/ 0025.html
Received on Tuesday, 15 April 2008 14:24:29 UTC