Re: Review of latest Widget Signature Draft

Thomas

Thanks for the careful review.

comments inline

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. ;-)
>
I thought we needed a namespace section so added one. It can use some  
refinement.
I considered adding a list of namespace URIs used, can do that.

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

ok

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

I suggest generically in 4.1

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

good, thanks

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

this is an open  issue regarding alignment

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

oops, thanks

> - 5.2 and 5.3 have an issue about additional algorithms.  I suggest
> just being silent about them.
>
ok to remove the issues?

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

we have a naming convention listed with the property sections. Should  
mention that here.


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

sounds reasonable

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

i think it is complicated , I'll think about better text, suggestions  
welcome.

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

agree, text on references would be useful.

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

so you suggest simplifying this to v3?

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

need to add something here

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

yes, hence the issues noted above

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

we should not profile but should mention best practice of certificate  
validtion and revocation checking

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

Received on Wednesday, 25 February 2009 12:51:58 UTC