Review of latest Widget Signature Draft

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

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

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

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


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


Not so editorial:

- In the example in 1.4, the signature doesn't cover the signature  
properties.

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

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

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

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

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

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

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

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

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

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

Received on Wednesday, 25 February 2009 12:07:26 UTC