On Apr 15, 2009, at 22:16, Frederick Hirsch wrote:
We are not using the transform chain where complexity and
performance issues occur,
The complexity concern I raised is that the last signing step needs to
run canonicalization and reserialization in order to get a byte stream
to sign when it would be simpler to use a detached signature that
signs the original uncanonicalized bytes. Running canonicalization
first requires more code.
If I've understood correctly, the idea is that widget support can be
added to an existing Web browser engine with smallish effort. It seems
to me that there is no pre-existing reason for a Web browser engine to
contain an implementation of canonicalization or XML signatures.
Is it a problem to use schema to express types (e.g. anyURI to mean
put a URI as an attribute value etc)
Yes, that's a problem if the URIs are meant to be dereferenced.
The lexical space of anyURI eventually was watered down to any string.
If you want to get an actual legal dereferencable URI from the value
of anyURI, you need to apply a conversion algorithm.
Since a widget engine is an augmented browser engine, it makes sense
to use the existing browser engine machinery for doing the attribute
value to legal URI conversion prior to dereferencing. In that case, it
makes more sense to reference http://lists.w3.org/Archives/Public/public-html/2009Mar/att-0444/draft.html
(which is what HTML and CSS use and browser engines implement) than
to reference something else from a non-browser-oriented working group.
OTOH, if you don't want to denote that the value is meant to be
treated as a dereferencable URI but merely as an identifier that get
compared code point for code point like a namespace "URI" gets
compared, what's the point of using anyURI as opposed to just using
string? With string you get the same lexical space without
interference of the real URI value space implications.
XML Security is also an existing solution since 2002 and is profiled
down in this case. There are already XML implementations.
Are those implementations already included for another reason in
browser engines that are going to be augmented to be widget engines?
If not, it seems to me they'd be new code bloat compared to
traditional non-XML crypto code that already lives in the libraries
that browsers use for their existing crypto operations.
And again, XML security solves a more complex problem than the
smallest problem that really needs solving for zip archive signing.
--
Henri Sivonen
[email protected]
http://hsivonen.iki.fi/
