Re: Widgets 1.0: Digital Signature, FPWD comments

Hi Frederick,

On Wed, Apr 16, 2008 at 12:22 AM, Frederick Hirsch
<frederick.hirsch@nokia.com> wrote:
>
>  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.

It's an emerging trend:) An increasing number of groups are moving
towards alternative means of creating and maintaining community
involvement around their specifications. Twitter provides an informal
way to alert people of changes to the specification as they happen,
without them having to directly subscribe to the mailing lists or
monitor CVS logs. For a lot of people, this is more convenient as
working groups often work on a large number of specifications (our WG
will soon have over 10 distinct specs, which makes for a lot of noise
if you are only interested in the goings on of one spec).

>  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.

Normative words in the specification are surrounded by <em> elements.
For editorial purposes, we currently style them with the color red.
However, I'll make sure that for print and for the final draft of the
specification, the style sheet does a text transform to uppercase.

>  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.

For the sake of interoperability, we were reluctant to point to
Canonicalization 1.1 because it is not yet a REC, and lack of evidence
that it is widely implemented. I guess if we had evidence that it was
natively implemented and shipped with, say, Java, C++, and C# then we
would be willing to point to it.

>  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.

Yes. The working group has not yet discussed how we are going to
handle versioning. However, it will be on the agenda for the F2F.

>  5) Should have a section listing namespaces and noting the fact that
> prefixes though used for illustration may vary when referring to the
> namespaces.

Added. The section reads:
"Namespaces
All elements in this specification operate within the namespaces
specified in [XMLDsig]. This specification does not define any
additional namespaces. "

As there is only one example in the specification, I have not put in
that "illustrations may vary when referring to the namespaces". If we
add more examples, I will certainly put that in.

>  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."

Done.

>  You should decide if the name is fixed in lowercase or not. State the
> naming rule here. Is SiGnAtURe.XmL allowed?

Ok, I've made it clear that the name is case insensitive. Also, the
processing model mandates a case insensitive match of signature.xml.

>  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:"

Done.

>  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]."

Yep, changed.

>  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?

I did have that in a previous draft, but Thomas suggested that we sign
the uncompressed representation. I guess this is where we need some
guidance from XMLSec about what approach we take.

>  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.

Agreed.

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

To be consistent with what we have said in our other widget
specifications, I've said:

"The procedure for signing a widget resource to produce a conforming
digital signature document is as follows. Implementations MAY perform
the following algorithm in an alternative manner so long so long as
the end result is indistinguishable from the result that would be
obtained by the following the specification."

>  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.

Done.

>  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."

Ok, I've included the text, but I have not gotten rid of the pseudo
code just yet. There are a few issues outstanding that the WG needs to
discuss before we remove it. However, I don't expect it to be in there
by the next publication.

Thanks!

Marcos
-- 
Marcos Caceres
http://datadriven.com.au

Received on Wednesday, 23 April 2008 04:42:19 UTC