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 <[email protected]>
