On Apr 14, 2009, at 13:01, Thomas Roessler wrote:
On 14 Apr 2009, at 11:42, Henri Sivonen wrote:
XSD datatypes are too vague, allow whitespace where the spec writer
didn't mean to allow whitespace or allow surprising values (like
"0" and "1" when the spec writer though (s)he'd be allowing "true"
and "false"). It is much safer to define datatypes in precise
English prose like HTML5 does than to expect XSD to match what is
really meant.
There's an interesting discussion to be had here; however, I doubt
it's in scope for this WG. (In other words, this strikes me as a
rathole.)
I don't see why widgets need to depend on XML signatures at all.
When you need to reserialize XML, you import all the troubles of
serializing XML (see e.g. https://issues.apache.org/bugzilla/buglist.cgi?query_format=advanced&product=Security&component=Canonicalization&cmdtype=doit
).
The only place where you actually need canonicalization is when
hashing the SignedInfo element inside the signature file (i.e.,
once per signature verification).
Given that the signature format is profiled down pretty heavily in
the widget signing spec, I'd dare a guess that most of the
complexity isn't ever used, so a careful implementation might be
able to write a c14n implementation that bails out on anything
that doesn't look like a signature that follows the constraints in
this format.
If you need to do canonicalization even in one place, you need a
properly debugged implementation of it. If the signature format is
profiled heavily, doesn't it mean you can't even use an off-the-
shelf implementation of XML signatures?
Much of the complexity of canonicalization (and signature in
general) comes from the need to deal with pretty arbitrary nodesets
generated by transform chains. The widget signature profile does
not use (i.e., it's a MUST NOT) any transform chains.
Since the use of transforms is a choice of the signature
application, you shouldn't have any trouble using existing toolkits.
This all seems like needless complexity to me. To sign a zip archive,
one needs a manifest file that contains digests for all the other zip
entries and a signature for the manifest file. Even if widgets use an
XML manifest instead of a jar-style plaintext manifest (which would be
supported by existing jar signing tools; analogously to the zip format
itself having been chosen due to pre-existing tool support), why would
one want to sign the manifest XML with the XML signature machinery
instead of signing it as a sequence of bytes using a well-established
detached signature format for signing a file of bytes?
--
Henri Sivonen
[email protected]
http://hsivonen.iki.fi/
