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