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 13:22:36 +0300
Cc: public-webapps <public-webapps@w3.org>
Message-Id: <4B8BFCD0-6E96-492E-9987-4290486BB9D5@iki.fi>
To: Thomas Roessler <tlr@w3.org>
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
Received on Tuesday, 14 April 2009 10:23:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC