Re: [widgets] Jar signing vs. XML signatures

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
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 16 April 2009 08:52:12 UTC