Widgets 1.0: Digital Signature, FPWD comments

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:28 UTC