Re: Review of latest Widget Signature Draft

Thomas

Thank you for your constructive comments on Widget Signature.

As outlined below, the latest draft incorporates changes to address  
your comments. Please let me know if any additional change is needed  
for the items that I indicate have been corrected in the draft. Unless  
I hear otherwise, I will assume the comments have been addressed  
adequately.

The latest draft is available at

http://dev.w3.org/2006/waf/widgets-digsig/

Redline is at http://dev.w3.org/2006/waf/widgets-digsig/Overview-diff.html

A few of your comments remain open but should be addressed soon

+ Text for ID based references
+ Timestamp and serial number, expiration

As you note the issue of second hash algorithm might be more difficult  
and may also depend on XML Signature 1.1 decisions, so that has not  
also been addressed.

Thanks

regards, Frederick

Frederick Hirsch
Nokia



On Feb 25, 2009, at 7:06 AM, ext Thomas Roessler wrote:

> In reviewing the latest draft, a couple of comments.
>
>   Widgets 1.0: Digital Signatures
>   Editor's Draft 23 February 2009
>   http://dev.w3.org/2006/waf/widgets-digsig/
>
> (Mostly) editorial:
>
> - I would propose including a table of namespace prefixes and
> namespace URIs, and just saying that the prefixes are editorial
> conventions.  The current text in 1.1 and 1.2 is a bit hard to refer
> to, and the text in 1.2 sounds like it comes from a time when
> namespaces were new.  (It is, since it's lifted straight from XML
> Signature 1.0. ;-)
>

The current editors draft includes a change to address this.

> - 4.2 claims that the author signature serves to determine "whether or
> not two widgets came from the same author". Actually, author
> signatures from the same identity can only confirm that they come from
> the same author; signatures from different identities could still be
> from the same author.  Strike "or not".
>

Change made in latest draft

> - 4.3 mentions that distributor signatures may have implications in
> security policies.  The same isn't said for author signatures.  I
> propose either saying this generically, or striking it from 4.3.
>

Modified to say generically

> - 4.3 says "no distributor signatures are to be included".  I know
> what that's supposed to mean, but think this might cause confusion.  I
> suggest to say something along the following lines:
>
>> The ds:Signature MUST include ds:References for all resources of the
>> widget including any author signatures, but excluding any
>> distributor signatures.  In other words, distributor signatures MUST
>> countersign author signatures, but MUST NOT countersign other
>> distributor signatures.
>
>

Adopted this text in latest draft

> - 5.1 says "as required by [XMLDSIG11]" -- I propose striking that,
> since this specification is making its own, possibly diverging choice
> of mandatory to implement algorithms.
>

Change made in latest draft.

>
> Not so editorial:
>
> - In the example in 1.4, the signature doesn't cover the signature
> properties.
>

Example updated in latest draft to do this.


> - 5.2 and 5.3 have an issue about additional algorithms.  I suggest
> just being silent about them.
>

Editors notes removed in latest draft

> - The processing model in 6.2 sounds as if it requires implementations
> to do a deep-dive into other signature files in order to determine
> whether an author signature, if present, is covered by a distributor
> signature.  That sounds error-prone.  I wonder if there should be a
> simple file name convention to distinguish author and distributor
> signatures, to make signature validation independent of parsing more
> than one signature resource.
>

This is taken care of by the file names, clarified in latest draft.


> - The processing model in 6.2 does not currently enforce the MUST NOT
> on distributor signatures countersigning each other.  I'm having a
> hunch that that might get abused by malevolent distributors in order
> to interfere with each other; I therefore suggest that distributorr
> signatures that countersign each other are a reason for validation
> failure.
>

Added this in latest draft

> - In 6.1, I wonder whether it's worthwhile to rebuild the signature
> properties piece a bit -- the current description is mildly convoluted
> (by describing a tree from the leaves, not the root).
>

Rewrote this section for clarity


> - We're not currently saying how same-document references are done.
> The example suggests ID-based references.  That should be said
> explicitly -- or else people might start using complex xpointers.  It
> might also be useful to recommend the use of random strings for the
> IDs.  Corresponding to that, the validation model does not enforce the
> position of the signature properties within the overall XML document.
> That might lead to interesting differences in implementations that
> could cause different implementations to see different things.
>

This remains to be added.

> - In 4.4, we currently perform a dance around X.509 version numbers.
> Thinking this through more thoroughly, it worries me that this came
> up, for the following reason:  You need an X.509 v3 extension to
> express the basic constraints on a certificate.  Without the basic
> constraints extension, it is impossible to distinguish a CA
> certificate from an end entity certificate.  Which in turn suggests
> that somebody might have inadvertently generated a CA certificate
> instead of an end entity certificate...  In other words, we shouldn't
> ever see an end entity certificate that is X.509 v1 or v2.  (And if we
> see one, it's a good idea to break it.)
>

Modified draft to require v3 and removed v1/v2 text. Included  
rationale given here.


> - The current draft has a relatively complex set of interacting
> signatures, but does not timestamp these at all.  I'd *really* like us
> to mandate a timestamp property on each of the signatures, and demand
> during validation that the timestamp MUST be in the past.  To give
> just one example, assume a distributor's signing process is found to
> be broken, but it's not practical to exchange the signature key.
> Being able to weed out all signatures made before a particular date
> might turn out really important in this context.  (In fact, I'm
> starting to wonder whether there should be a timestamp and a serial
> number...)
>

To be done

> - I wonder whether we should be keeping an additional hash algorithm
> in reserve, too. (That's a question that needs to go back to the XML
> Security WG.)
>

Open issue

> - I'm worried that we don't say anything about revocation of
> signatures.  I'd like to revisit why this is the case, and whether
> there's anything we can do about it.
>

Added text regarding this, see section 6.2 item 6.
Pl

> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>

Received on Tuesday, 3 March 2009 23:42:18 UTC