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
