W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [widgets] Jar signing vs. XML signatures

From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 14 Apr 2009 12:42:20 +0300
Cc: public-webapps <public-webapps@w3.org>
Message-Id: <7CA676DD-C5BC-487C-A257-FF70199111C4@iki.fi>
To: Thomas Roessler <tlr@w3.org>
On Apr 14, 2009, at 11:57, Thomas Roessler wrote:

> On 14 Apr 2009, at 10:27, Henri Sivonen wrote:
>
>> Wouldn't it be simpler to use jar signing instead of inventing a  
>> new way of signing zip files with implementation dependencies on  
>> XML signatures and spec dependencies on XSD? (Why does the spec  
>> have dependencies on XSD?)
>
> Which XSD dependency do you mean?  The only XSD dependencies I could  
> think of right now are ones that say things like "the value of this  
> attribute is of type anyURI" or "the value space of this element is  
> a restriction on the base64Binary XSD type."  XML Signature does not  
> require schema validation, or anything like that.

Hence, "spec dependencies".

I don't find the string anyURI in the spec, but anyURI is a great  
example of why defining syntax in terms of XSD datatypes is a bad idea:
http://hsivonen.iki.fi/thesis/html5-conformance-checker#iri

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.

>> 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?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Tuesday, 14 April 2009 09:43:10 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT